Let's suppose messages are received from a unit with the following parameters:

• odometer, which displays the distance in kilometers traveled between the last two messages;
• fuel_consumption, which displays the fuel in liters spent between the last two messages.

The client needs a sensor that will show real-time consumption in km/l.

Here is the solution using validation:

1. Create an Instant fuel consumption sensor named InsFCS based on the fuel_consumption parameter.
   
2. Create a Custom sensor named Consumption with km/l as a unit of measurement. Specify the odometer as a parameter. In the properties of the Consumption sensor, specify the InsFCS sensor as a validator and choose the Divide sensor by validator validation type.
   

The solution using an expression:

1. Create a sensor with the Relative odometer type named Relative mileage based on the odometer parameter.
   
2. Create an Instant fuel consumption sensor named InsFCS based on the fuel_consumption parameter.
   
3. Create a Custom sensor named Consumption with km/l as a unit of measurement. Use a formula with the names of the previously created sensors in square brackets: [Relative mileage]/[InsFCS].
   

As you can see, when using validation, it is enough to create 2 sensors, not 3. In this case, however, none of the sensors will show the mileage value between messages. Nevertheless, if you need to create a sensor with the Relative odometer type for solving other tasks, then the solution using an expression will be more convenient.

Let's suppose the following sensors are created in the unit:

• Fuel level sensor named FLS, which is based on the parameter fuel_lvl;
• The Voltage sensor named Voltage, which is based on the parameter pwr_ext.

When the voltage value drops below 9 volts, an analog fuel level sensor shows incorrect values. To control fuel properly, it is necessary to get rid of false readings.

In this case, it is necessary to follow the next steps:

1. Create a Custom digital sensor named Sufficient voltage based on the [Voltage] expression.
   
2. Add a calculation table with the following rows:
   X=0; a=0; b=0
   X=9; a=0; b=1
   
3. In the properties of FLS, specify the Sufficient voltage sensor as a validator and select Not-null check as the type of validation.
   

Now, when the voltage drops below 9 volts, the Sufficient voltage sensor will have a value of 0 (Off), therefore, the not-null check will not be passed, so the FLS readings will be replaced with a dash (N/A). This will exclude incorrect data from the analysis.

Let's suppose that messages with the following parameters were received from the unit within the reporting interval:

• adc1, which displays the fuel level in volts according to the previously installed fuel level sensor (the parameter is missing in new messages);
• param4, which displays the fuel level in volts according to the new fuel level sensor (the parameter is missing in old messages).

It is necessary to set up the sensors so that the report can display data on fuel from both old and new sensors.

In such a case, follow these steps:

1. Create a Fuel level sensor named FLS (old) based on the adc1 parameter. It is necessary to enter the old calibration table into the FLS (old) calculation table to convert volts to liters.
   
   
2. Create a Fuel level sensor named FLS based on the param4 parameter. It is necessary to enter the new calibration table into its calculation table to convert volts to liters. In the properties of FLS, specify the FLS (old) sensor as a validator and select the Replace sensor with validator in case of error as a type of validation.
   
   

Let's suppose that messages are received from the unit containing the following parameters:

• fls_rs485, which displays the fuel level in volts according to the installed fuel level sensor;
• fuel_lvl, which displays the fuel level in liters according to the factory-installed fuel level sensor.

The installed FLS is more accurate, but sometimes it displays an error, and once it happens, the client wants to see the readings of the factory-installed FLS.

In this case, it is necessary to follow the next steps:

1. Create a Custom sensor named Factory-installed FLS based on the fuel_lvl parameter.
   
2. Create a Fuel level sensor named FLS based on the fls_rs485 parameter. It is necessary to enter a calibration table into the FLS calculation table to convert volts to liters. In the properties of FLS, specify the Factory-installed FLS sensor as a validator and select Replace sensor with validator in case of error as the type of validation.
   
   

Let's suppose that messages are coming from a unit containing the following parameters:

• in3, which equals 0 when the attachment equipment is turned off, or 1 when it is turned on;
• in4, which equals 0 when the rear door is closed, or 1 when it is open.

It is necessary to create a sensor that will be activated when the attachment equipment is on and the rear door is open.

In this case, it is necessary to do the following steps:

1. Create a Custom digital sensor named Attachment equipment, based on parameter in3.
   
   
2. Create a Custom digital sensor named Rear door is open when the equipment is on based on parameter in4. Then select the Attachment equipment sensor as the validator and choose the Logical AND validation type.
   
   

Let's suppose that messages are coming from a unit containing the following parameters:

• door11, which equals 0 when the left front door is closed, or 1 when this door is open;
• door12, which equals 0 when the right front door is closed, or 1 when this door is open.

It is necessary to create a sensor that will be activated when at least one of the front doors of the car is open.

In this case, follow these steps:

1. Create a Custom digital sensor named Left front door is open, based on parameter door11.
   
   
2. Create a Custom digital sensor named Front doors are open, based on parameter door12. Then specify the Left front door is open sensor as the validator and choose the Logical OR validation type.
   
   

Let's suppose that we receive messages from the unit with a 16-bit parameter can_a1 that contains information about different systems of the unit. Based on the tracker documentation, information about the fuel level is contained in the 8 least significant bits of the parameter. It is necessary to verify this and extract part of the parameter from the 8 least significant bits to create a fuel level sensor based on them.

For example, when a 100-liter tank is filled up to 40%, the value of the parameter can_a1 may have the following values:

As you can see, the value of the parameter can_a1 can change in decimal representation. But at the same time, the 8 least significant bits of the parameter remain unchanged (they are highlighted in blue), as the amount of fuel in the tank does not change. If we convert the values of the 8 least significant bits into decimal, we get:

(BIN) 0110 0110 = (DEC) 102

The maximum value that can be stored in 8 bits is:

(BIN) 1111 1111 = (DEC) 255

Using simple arithmetic operations, we verify that 102/255 = 40/100 = 0.4. This brings us to the conclusion that the 8 least significant bits of the parameter indeed correspond to a tank filled up to 40%.

To extract the first part of the parameter, you need to follow these steps:

1. Create a Custom sensor named 8 least significant bits based on the const255 parameter.
   
2. Create a Fuel level sensor named FLS based on the can_a1 parameter. Then select the 8 least significant bits sensor as a validator and choose Math AND validation type. Also, it is necessary to enter a calibration table into the sensor calculation table to convert the result into liters.
   
   

Since each bit can have different values in different messages, let's label the least significant bits as b and the most significant ones as B:

As a result, using the binary representation of the number 255, the can_a1 parameter was filtered in such a way as to leave only the 8 least significant bits in it.

Let's suppose that we receive messages from the unit with a 16-bit parameter can_b2 that contains information about different systems of the unit. Based to the tracker documentation, information about the fuel level is contained in the 8 most significant bits of the parameter. It is necessary to verify this and extract part of the parameter from the 8 most significant bits to create a fuel level sensor based on them.

For example, when a 200-liter tank is filled up to 60%, the value of the parameter can_b2 may have the following values:

As you can see, the value of the parameter can_b2 can change in decimal representation. But at the same time, the 8 most significant bits of the parameter remain unchanged (they are highlighted in blue), as the amount of fuel in the tank does not change. If we convert the values of the 8 most significant bits into decimal, we get:

(BIN) 1001 1001 = (DEC) 153

The maximum value that can be stored in 8 bits is:

(BIN) 1111 1111 = (DEC) 255

Using simple arithmetic operations, we verify that 153/255 = 120/200 = 0.6. This brings us to the conclusion that the 8 most significant bits of the parameter indeed correspond to a tank filled up to 60%.

To extract the second part of the parameter, it is necessary to do the following:

1. Create a Custom sensor named 8 most significant bits based on the parameter const65280.
   
2. Create a Custom sensor named Filtered bits based on the parameter can_b2. Then select the 8 most significant bits sensor as a validator and select the Math AND validation type.
   
   
3. Create a Fuel level sensor named FLS based on the expression [Filtered bits]/const256. It is necessary to enter a calibration table into its calculation table to convert the result into liters.
   
   

Since each bit can have different values in different messages, let's label the least significant bits as b and the most significant ones as B:

Shifting bits down by several digits occurs through division by 2 to the power, which is equal to the number of digits to shift. In this case, we need an offset by 8 digits, so division is carried out by 2⁸ = 256.

As a result, using the binary representation of the number 65280, the can_b2 parameter was filtered in such a way as to leave only the 8 most significant bits in it, and then they were converted into the least significant bits using the offset.